![[新サービス] Amazon File Cache が一般提供されました](https://devio2023-media.developers.io/wp-content/uploads/2019/11/aws-eyecatch.png)
[新サービス] Amazon File Cache が一般提供されました
しばたです。
今年の8月に開催されたAWS Storage Day 2022で発表された新サービスであるAmazon File Cacheが正式リリースされました。
AWSからのアナウンスはこちらになります。
本記事ではAmazon File Cacheの概要を解説します。
Amazon File Cache とは
Amazon File Cacheはその名前の通りファイルサーバーに対する高速なキャッシュを提供するキャッシュサーバーを提供するサービスとなります。
(AWS Storage Day 2022キーノートのスクリーショットを引用)
Amazon File Cacheがサポートしているファイルサーバーは以下となっています。
- Amazon S3 バケット
- AWSで提供されるNFSサーバー (NFS v3でDNSアクセスできるもの)
- Amazon FSx for OpenZFS
- Amazon FSx for NetApp ONTAP
- オンプレ環境のNFSサーバー (NFS v3)
要はS3バケット or NFS v3のNFSサーバーといった感じなのですが、Amazon EFSがサポート対象かは明記されていませんでした。
(EFSについては実際に環境を作って動作確認するしかなさそうです...)
そしてAmazon File Cacheを利用可能なクライアントは本日時点で
- Lustre ClientをインストールしたEC2インスタンス
- Lustre Clientがサポートされるディストリビューションである必要あり
- EC2ホストのECSコンテナ
- Lustre Clientのセットアップが必要
- Fargateは非サポート
となっています。
Amazon File Cacheのドキュメントを読み込むと、どうやらこのサービスはFSx for Lustreをベースにカスタマイズしたものの様でFSx for Lustreと同様の制約がいろいろなところに存在しています。
このため利用クライアントにLustre Client(Ver.2.12以降)をインストールする必要がある模様です。
利用可能リージョン
本日時点でAmazon File Cacheを利用可能なリージョンは以下となります。
- US East (N. Virginia)
- US East (Ohio)
- US West (Oregon)
- Canada (Central)
- Europe (Frankfurt)
- Europe (Ireland)
- Europe (London)
- Asia Pacific (Tokyo)
- Asia Pacific (Singapore)
- Asia Pacific (Sydney)
東京リージョンはサポートされてますが大阪リージョンではまだ使えません。
ただ、東京リージョンのなかでもAZapne1-az1がFSx for Lustreと同様に非サポートでした。
料金
料金ページは以下となります。
Amazon File Cacheの料金は大きく以下の二種類あります。
- ストレージ利用費 : キャッシュおよびメタデータの利用量に応じた費用 (GB-months単位、秒単位の日割りあり)
- データ転送量 : AZおよびVPC Peeringを跨ぐ場合の"in","out"の転送料 + リージョンを跨ぐ場合の"out"の転送料
この点もFSx for Lustreと同様です。
ただ、気を付けないといけない点として、
- ストレージスループットがTiB当たり 1000 MB/s と極めて高性能
- Amazon File Cacheの最低ストレージ容量は 1.2 TiB (FSx for Lustreと同様)
- ストレージ利用単価が同等スループット比でFSx for Lustreの約2倍強
であり、ストレージ利用費が高額になりやすいので導入の際には事前にコスト見積もりをしておくことをお勧めします。
一例を上げると、本日時点の東京リージョンではストレージ単価が$1.641 per GB-monthのため最低容量の1.2TiB (1200GB)を選択しても毎月(30日)のストレージ利用費だけで$1,969.25[1]とかなり高額になります。
実際にはさらに転送料金がかかります。
試してみた
今回はS3バケットに対するキャッシュ環境を作って動作確認してみます。
良い感じのデータが無いのと、まずは利用手順を確認したいので性能評価までは行いません。
私の検証AWSアカウントの東京リージョンに用意したVPC上にS3 + Amazon File Cache環境と接続確認用のEC2インスタンスを構築します。
ドキュメントがLustre Client Ver.2.12以降を前提としていたのでAmazon Linux 2ではなくUbuntu 22.04を使っています。
(ただ、後で確認したところAmazon Linux 2, Lustre Client Ver.2.10でもエラーは出ませんでした)
S3の準備
まずはS3から用意します。
今回amazon-file-cache-test-20221001という名前のS3バケットを東京リージョンに作成しました。
- ACL無効
- パブリックアクセスブロック
- デフォルト暗号化有効 (SSE-S3)
- なお、SSE-KMSを使う場合は別途バケットポリシーの設定が必要
と最低限の設定を行ったPrivateなバケットとしています。
そしてとりあえずのテスト用ファイル(hello-world.txt)をアップロードしておきます。
セキュリティグループの準備
Amazon File Cacheではインバウンド通信を受けるためのセキュリティグループを一つ設定する必要があります。
このセキュリティグループではLustreのポート(TCP 988,1021-1023 UDP 988,1021-1023)を開ける必要があり、NFSのポート(TCP 2049, UDP 2049)ではないのでご注意ください。
ちなみにセキュリティグループの設定を誤ると環境構築時に以下のエラーメッセージが表示されます。
The file cache cannot be created because the default security group in the subnet provided or the provided security groups do not permit Lustre LNET network traffic on port 988
Amazon File Cacheの構築
ここからAmazon File Cacheの構築を行います。
Amazon File Cacheはマネジメントコンソール上はAmazon FSxの一部として扱われています。
Amazon FSxのホーム画面から左ペインの「キャッシュ」を選ぶと一覧表示画面になります。
ここから「キャッシュを作成」ボタンをクリックして新規に環境を作ります。
最初にキャッシュ名とストレージ容量、配置するサブネットを指定します。
ストレージ容量は1.2TiBまたは2.4TiB刻み(2.4,4.8,7.2...)で指定し、スループットキャパシティは容量に応じて自動設定[2]されます。
サブネット指定は環境に応じて行い、セキュリティグループに前節で作ったものを指定します。
ストレージの暗号化は必須です。
今回はデフォルトのキーをそのまま選んでいます。
次のページに遷移するとキャッシュ元(Link data repositories)の設定になります。
画面下部にリポジトリの指定欄がありNFSかS3かを選択できます。
今回はS3を選択し、以下の内容を設定しています。
- Data repoository path : バケットのURL
s3://amazon-file-cache-test-20221001/ - Cache path : 任意のパス(今回は
/s3test)
Amazon File Cacheは複数のS3バケットをキャッシュ元にすることが可能で、Cache pathはその際のルートを分けるためのパスとなります。
「追加」ボタンをクリックすると画面上部のData repository assosiations欄に入力内容が追加されます。
必要な分の設定を終えたら次の画面に遷移します。
最後に入力内容の確認画面になるので、内容に間違いがないことを確認し「キャッシュを作成」ボタンをクリックします。
キャッシュの作成が始まりますので完了まで待ちます。
今回はだいたい10分程度で完了しました。
詳細画面を開くとこんな感じです。
Cache typeがLustreでバージョン2.12だそうです。
キャッシュが作成されるとVPCのDNS(Route 53 Resolver)から参照可能なDNS名が割り当てられ、これとマウント名がクライアントからの利用に必要となります。
画面下部の各タブについて、まず「ネットワークとセキュリティ」はこんな感じです。
配置ネットワーク情報が表示されます。
次に「管理」はこんな感じです。
週次のメンテナンスウィンドウの時間を変更可能となっています。
「データリポジトリ」はこんな感じで、キャッシュ元リポジトリの情報が表示されます。
最後に「タグ」はタグのメンテナンス欄です。
また、「アタッチ」ボタンをクリックすると下図の様にクライアントからの接続手順がポップアップで表示されます。
補足 : DNS名とENIについて
DNS名はVPCのDNS(Route 53 Resolver)に登録され、内容を確認すると以下の様にPrivate IPを返します。
パブリックなレコードでは無いのでVPC外から利用したい場合はRoute 53 Resolver inbound endpointが必要になるでしょう。
# VPCのDNSからのみ回答可能
$ dig fc-0e3a84xxxxxxxxxxx.fsx.ap-northeast-1.amazonaws.com +short
10.0.21.154
また、上の結果から「Amazon File Cache用のENIが一つ生えてるだろうな。」と思い確認したところ何故か5つも生えてました。
一つはDNS名で使っているものでしたが残りの4つの用途は不明です。
予想になりますが、たぶん、NFSをキャッシュ元とした際にキャッシュ元へのアクセスに使うのだろうと思っています。
EC2の準備
キャッシュの準備ができたので次にEC2の準備を行っていきます。
前述の通りドキュメントの手順がUbuntu 22.04を使ってたので今回はこれに従いUbuntu環境を準備しています。
EC2インスタンスの作成手順は割愛します。
作成したEC2インスタンスにログインし、以下の手順でカーネルのアップデートとLustre Clientのインストールを行います。
# Ubuntu 22.04の場合
$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 22.04.1 LTS"
# AWS Lustre client Ubuntu repository の登録
wget -O - https://fsx-lustre-client-repo-public-keys.s3.amazonaws.com/fsx-ubuntu-public-key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/fsx-ubuntu-public-key.gpg >/dev/null
sudo bash -c 'echo "deb [signed-by=/usr/share/keyrings/fsx-ubuntu-public-key.gpg] https://fsx-lustre-client-repo.s3.amazonaws.com/ubuntu jammy main" > /etc/apt/sources.list.d/fsxlustreclientrepo.list && apt-get update'
# カーネルバージョンが 5.15.0.1020-aws 以前の場合はカーネルの更新を先にする
uname -r
# 今回は 5.15.0-1019-aws だったので更新+再起動
# ※カーネル更新と同時にLustre Clientもインストールしている
sudo apt install -y linux-aws lustre-client-modules-aws && sudo reboot
# 結果 5.15.0-1019-aws → 5.15.0-1020-aws へ更新される
Lustre Clientを使うためにカーネルバージョンの指定がある以外は特に問題のない手順でしょう。
インストール後の結果はこんな感じです。
# Lustre関連機能のチェック
$ dpkg -l | grep lustre
ii lustre-client-modules-5.15.0-1020-aws 2.12.8-1fsx5 amd64 Lustre Linux kernel module (kernel 5.15.0-1020-aws)
ii lustre-client-modules-aws 5.15.0.1020.20 amd64 Lustre kernel modules for Amazon Web Services (AWS) systems.
ii lustre-client-utils 2.12.8-1fsx5 amd64 Userspace utilities for the Lustre filesystem (client)
# インストールされたバージョンの確認
$ lfs --version
lfs 2.12.8
接続確認
これで準備ができたので実際に接続確認をしてみます。
EC2のコンソール上で次の手順でmountコマンドを実行します。
# (Optional) マウントディレクトリを作成
sudo mkdir -p /mnt
# mountコマンド実行
sudo mount -t lustre -o relatime,flock fc-0e3a84xxxxxxxxxxx.fsx.ap-northeast-1.amazonaws.com@tcp:/g2jxxxxx /mnt
mountコマンドの指定はマネジメントコンソールの「アタッチ」で提示されたものをそのままコピペすればOKです。
一応書式を解説すると以下の様になります。
# -t lustre 指定にし、DNS名とマウント名が必要
sudo mount -t lustre -o relatime,flock "DNS名"@tcp:/"マウント名" "マウントポイント"
mountコマンドがエラー無く終了すれば成功です。
あとはマウントポイント(今回は/mnt/)にアクセスしてやればキャッシュへ透過的にアクセスしてくれます。
# マウントポイントの配下に「キャッシュパス」が付く
$ ls /mnt/
s3test
# キャッシュパス配下がS3バケットとなり、バケットにあるファイルが参照できる
$ ls /mnt/s3test/
hello-world.txt
# ファイルの中身もちゃんと参照できる
$ cat /mnt/s3test/hello-world.txt
Hello Amazon File Cache!
ちなみにdfコマンドの結果はこんな感じです。
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 7941576 2215396 5709796 28% /
tmpfs 494692 0 494692 0% /dev/shm
tmpfs 197880 820 197060 1% /run
tmpfs 5120 0 5120 0% /run/lock
/dev/xvda15 106858 5329 101529 5% /boot/efi
tmpfs 98936 4 98932 1% /run/user/1000
10.0.21.154@tcp:/g2jxxxxx 1201383168 10240 1201370880 1% /mnt
なお、マウントしたディレクトリへの直接書き込みは出来ませんでした...
AWS Storage DayのセッションではWrite Back可能とあったので私の設定が悪いだけかもしれません。
単純にアクセス権の設定が漏れてました...
私が普段全然NFSを使わないことが露呈してしまいお恥ずかしい限りです。
マウントしたディレクトリのアクセス権を設定すれば普通に書き込みも可能です。
# 単純にアクセス権の設定を忘れてました...
# ※本来なら mount -o rw の方が良い気がしますが動作確認なのでとりあえずこれで...
$ chmod 777 /mnt/s3test/
# 書き込み権限があれば普通に新規ファイルを作成可能
$ sudo echo "write test" > /mnt/s3test/write-test.txt
# ローカルからは直ちに参照可能
$ cat /mnt/s3test/write-test.txt
write test
ただ、書き込んだファイルは直ちにキャッシュ元に反映されはせず、lfs hsm_archiveコマンドでエクスポートする必要がある模様です。
対象ファイルにlfs hsm_archiveコマンドを実行しエラー無く完了すればS3バケットにファイルが追加されます。
# 対象ファイルをキャッシュ元(S3バケット)にエクスポート
$ sudo lfs hsm_archive /mnt/s3test/write-test.txt
# 結果確認
$ sudo lfs hsm_state /mnt/s3test/write-test.txt
/mnt/s3test/write-test.txt: (0x00000009) exists archived, archive_id:1
補足 : S3へのアクセス経路について
今回Amazon File Cacheを配置するサブネットをNAT GatewayもVPC Endpoint(Gateway)も無い完全に閉じたPrivateサブネットにしたのですが、特に問題なく利用できました。
S3へのアクセスはAWS Managedな領域から行っている様です。
キャッシュの削除
動作確認が終わったので最後にキャッシュを削除します。
対象となるファイルキャッシュを選択し「アクション」から「ファイルキャッシュを削除」を選びます。
確認ダイアログが表示されるのでキャッシュIDを入力し「削除」ボタンをクリックしてやれば削除処理が開始されます。
あとはしばらく待てば完全に削除されます。
その他
動作確認は以上となりますが、ドキュメントを読んで気になった点をいくつか紹介します。
1. オンプレNFSサーバーを利用する場合
オンプレ環境のNFSサーバーをキャッシュ元にする場合の前提条件は以下に記載されています。
ここから重要な点をいくつかピックアップすると、
- NFS v3であること
- オンプレ側アドレスはRFC 1918に準拠するPrivateネットワークであること
- Amazon File Cacheからアクセス可能なIP、名前解決可能なホスト名であること
- オンプレ環境とVPCはDirect ConnectかSite-to-Site VPN接続されていること
とあり、オンプレ環境とVPCがPrivateに接続されている必要があるのでご注意ください。
2. パフォーマンス
おそらく本記事をご覧の皆さんは性能面の情報も知りたいだろうと思うのでこちらを紹介しておきます。
3. メンテナンスウィンドウ
Amazon File Cacheも他のFSxシリーズと同様に週次のメンテナンスウィンドウが存在します。
ドキュメントよれば
Patching occurs infrequently, typically once every several weeks. Patching should require only a fraction of your 30-minute maintenance window. During these few minutes of time, your cache will be temporarily unavailable.
とのことでメンテナンス中の数分間はキャッシュアクセスできなるなることがあるそうです。
追記 : EFSとの組み合わせについて
本記事の公開後Amazon EFSと組み合わせて使えるか試してみました。
結果は失敗に終わり、残念ながらAmazon EFSは非サポートの模様です。
最後に
今回はシンプルに動作確認だけ行いました。
性能評価は環境依存な部分もあり、私個人として良さげな環境も持っておらず検証しにくいので他の方に託したい今日この頃です。
![[レポート] Amazon File Cache でコンピューティング・ワークロードを高速化 #STG218 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022_session-report.png)
